The committers listed above are authorized under a signed CLA.

• ✅ login: dimitrisgiannopoulos / name: Dimitrios Giannopoulos (6468f23)
• ✅ login: dimitrisgiannopoulos / name: Dimitris Giannopoulos (29487e8, 7a640db, f184b80)

Hi @albertoramosmonagas, thanks for pointing that out. I restored the template file and moved my proposal into a new document under documentation/APIBacklog/.

Hi @dimitrisgiannopoulos, Thanks for the update. This is a much stronger version of the proposal. The added delimitation table and the minimal API contract sketch make the intent much clearer.

That said, the updated text also reinforces the main concern from the backlog side: the proposal now looks even more like a distinct capability than a natural extension of OED, since it changes timing, input context, functional objective, and response semantics.

So the key question for discussion is no longer whether the proposal is understandable, but whether OED is really the right home for it. As this is being proposed as an enhancement of an existing API, input from the OED maintainers will be essential for backlog evaluation.

@dimitrisgiannopoulos Is this proposal based on an issue / discussion within the EdgeCloud Sub Project? Do you have references to the issues/minutes of this discussion? I would consider this as the right path before the API Backlog working group is considering the proposal.

@hdamker thanks for the clarification.

I had understood the API Backlog Working Group to be the right entry point for submitting the proposal, so I brought it here first and had not yet discussed it with the EdgeCloud subproject.

At the same time, based on @albertoramosmonagas ’s comment, I understand there is also a valid question as to whether this should remain an enhancement to OptimalEdgeDiscovery or instead be treated as a separate API in the EdgeCloud family.

Given that, what would you recommend as the best next step?

Should we use Thursday’s API Backlog meeting to discuss the proposal at a high level and determine whether it should proceed as an OED enhancement or as a new API, and then follow up with the Edge Cloud subproject accordingly?

Or would you recommend pausing the API Backlog discussion here and first taking it to the EdgeCloud subproject before continuing?

@dimitrisgiannopoulos Scope extensions of existing APIs or Sub Projects are best discussed first in their context, and then brought together with the support of the API / Sub Project team into API Backlog. In the concrete case I will leave the guidance to @albertoramosmonagas, but I see that he also wrote:

As this is being proposed as an enhancement of an existing API, input from the OED maintainers will be essential for backlog evaluation.

Thanks @dimitrisgiannopoulos. I suggest we still use Thursday’s API Backlog meeting for a first high-level discussion, mainly to assess the key classification question: whether this is better handled as an OED enhancement or as a separate API/capability within the EdgeCloud family.

Since this touches an existing API, input from the OED / EdgeCloud maintainers will be important, and we can use the backlog discussion to frame the follow-up with the subproject accordingly.